MKE must preserve any information necessary to determine the cause of the disruption or failure.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-260932	CNTR-MK-000980	SV-260932r966153_rule		Medium

Description
When a failure occurs within MKE, preserving the state of MKE and its components, along with other container services, helps to facilitate container platform restart and return to the operational mode of the organization with less disruption to mission essential processes. When preserving state, considerations for preservation of data confidentiality and integrity must be taken into consideration.

Description

When a failure occurs within MKE, preserving the state of MKE and its components, along with other container services, helps to facilitate container platform restart and return to the operational mode of the organization with less disruption to mission essential processes. When preserving state, considerations for preservation of data confidentiality and integrity must be taken into consideration.

STIG	Date
Mirantis Kubernetes Engine Security Technical Implementation Guide	2024-06-17

Details

Check Text ( C-64661r966151_chk )
When using Swarm orchestration, this check is Not Applicable. Review the Kubernetes configuration to determine if information necessary to determine the cause of a disruption or failure is preserved. Notes: - The ReadWriteOnce access mode in the PVC means the volume can be mounted as read-write by a single node. Ensure the storage backend supports this mode. - Adjust the sleep duration in the writer pod as needed. - Ensure that the namespace and PVC names match the setup. Steps to verify data durability: 1. Create a namespace to manage the testing: apiVersion: v1 kind: Namespace metadata: name: stig 2. PersistentVolumeClaim (PVC): Ensure a PVC is created. If using a storage class like Longhorn, it would look similar to: apiVersion: v1 kind: PersistentVolumeClaim metadata: name: stig-pvc namespace: stig spec: accessModes: - ReadWriteOnce storageClassName: longhorn # Replace with your storage class if different, e.g. NFS resources: requests: storage: 5Gi 3. Deploying the Initial Pod: Create a pod that writes data to the PVC. This pod will use a simple loop to write data (e.g., timestamps) to a file on the mounted PVC. Example: apiVersion: v1 kind: Pod metadata: name: write-pod namespace: stig spec: volumes: - name: log-storage persistentVolumeClaim: claimName: stig-pvc containers: - name: writer image: busybox command: ["/bin/sh", "-c"] args: ["while true; do date >> /data/logs.log; sleep 10; done"] volumeMounts: - name: log-storage mountPath: /data 4. Simulate Pod Failure: After the pod has been writing data for some time, it can be deleted to simulate a failure by executing the following: kubectl delete pod write-pod -n stig 5. Deploying a New Pod to Verify Data: Deploy another pod that mounts the same PVC to verify that the data is still there. apiVersion: v1 kind: Pod metadata: name: read-pod namespace: stig spec: volumes: - name: log-storage persistentVolumeClaim: claimName: stig-pvc containers: - name: reader image: busybox command: ["/bin/sh", "-c"] args: ["sleep infinity"] volumeMounts: - name: log-storage mountPath: /data 6. Verify Data Persistence: Check the contents of the log file in the new pod to ensure that the data written by the first pod is still there by executing the following: kubectl exec read-pod -n stig -- cat /data/logs.log If there is no log data, this is a finding.

Check Text ( C-64661r966151_chk )

When using Swarm orchestration, this check is Not Applicable.

Review the Kubernetes configuration to determine if information necessary to determine the cause of a disruption or failure is preserved.

Notes:
- The ReadWriteOnce access mode in the PVC means the volume can be mounted as read-write by a single node. Ensure the storage backend supports this mode.
- Adjust the sleep duration in the writer pod as needed.
- Ensure that the namespace and PVC names match the setup.

Steps to verify data durability:
1. Create a namespace to manage the testing:

apiVersion: v1
kind: Namespace
metadata:
name: stig

2. PersistentVolumeClaim (PVC):
Ensure a PVC is created. If using a storage class like Longhorn, it would look similar to:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: stig-pvc
namespace: stig
spec:
accessModes:
- ReadWriteOnce
storageClassName: longhorn # Replace with your storage class if different, e.g. NFS
resources:
requests:
storage: 5Gi

3. Deploying the Initial Pod:
Create a pod that writes data to the PVC. This pod will use a simple loop to write data (e.g., timestamps) to a file on the mounted PVC. Example:

apiVersion: v1
kind: Pod
metadata:
name: write-pod
namespace: stig
spec:
volumes:
- name: log-storage
persistentVolumeClaim:
claimName: stig-pvc
containers:
- name: writer
image: busybox
command: ["/bin/sh", "-c"]
args: ["while true; do date >> /data/logs.log; sleep 10; done"]
volumeMounts:
- name: log-storage
mountPath: /data

4. Simulate Pod Failure:
After the pod has been writing data for some time, it can be deleted to simulate a failure by executing the following:

kubectl delete pod write-pod -n stig

5. Deploying a New Pod to Verify Data:
Deploy another pod that mounts the same PVC to verify that the data is still there.

apiVersion: v1
kind: Pod
metadata:
name: read-pod
namespace: stig
spec:
volumes:
- name: log-storage
persistentVolumeClaim:
claimName: stig-pvc
containers:
- name: reader
image: busybox
command: ["/bin/sh", "-c"]
args: ["sleep infinity"]
volumeMounts:
- name: log-storage
mountPath: /data

6. Verify Data Persistence:
Check the contents of the log file in the new pod to ensure that the data written by the first pod is still there by executing the following:

kubectl exec read-pod -n stig -- cat /data/logs.log

If there is no log data, this is a finding.

Fix Text (F-64569r966152_fix)
When using Swarm orchestration, this check is Not Applicable. This is a catastrophic error, contact Mirantis support.